In many communication services of today, data packets are conveyed between different communicating parties over public packet-switched IP (Internet Protocol) networks. In this process, data packets from a sending party are transmitted through multiple interconnected routers in a transmission path to a targeted receiving party. When receiving an incoming data packet, each router performs a forwarding operation to determine the “next hop” for the packet, i.e. the next router in the transmission path, and move the packet towards its destination. It is well-known in the art that different packets of a session may take different routes between two communicating parties, e.g. depending on the network load and other factors influencing forwarding decisions made in the routers.
The communication parties discussed in this description may involve any equipment capable of packet-based communication, such as fixed and mobile telephones, computers, servers, game stations, etc. Here, the terms “sender” and “receiver” will often be used for short to represent any packet sending equipment and packet receiving equipment, respectively, being end points in a session of transferring data packets from the sender to the receiver over a network with routers or equivalent nodes.
In FIG. 1, the basic structure of a conventional router 100 is shown, when operating in a packet-switched network. The router 100 comprises an ingress part 100a, an egress part 100b and a forwarding function 100c, the latter being used for determining the next hop for an incoming data packet. The egress part 100b comprises a plurality of outgoing ports PA, PB, PC, . . . for links to different neighbouring routers A, B, C, . . . , respectively. Once a next hop to router C is determined in the forwarding function 100c, the packet can be sent out on the outgoing port PC associated to that router.
When an incoming data packet 102 basically having a payload field PL and a header H, is received at the ingress unit 100a, the forwarding function 100c determines which next router the packet should be sent to, typically based on destination information in the header H. In this example, the header information in the packet allows for router C as the next suitable hop, and the packet 102 is therefore sent out on the corresponding port PC which is connected to router C.
Each communication party has typically been assigned an IP address which is included in the packet header information and may be used in the forwarding operation above for routing any data packets directed towards that communication party. The communication party may also have been assigned a host name, such as user@operator.com, which is associated with an IP address in a DNS (Domain Name Server) system. Thus, when queried by a sender with a host name of a targeted receiver, the DNS will provide the current IP address of the receiver which the sender can include as destination address in any data packets directed to that receiver. Forwarding decisions can then be made in the routers based on the destination address in the packets.
However, packet-switched networks using IP (Internet Protocol) addressing such as the Internet have generally unsatisfactory support for security. Thus, it has been found necessary or desirable to protect the packets from being intercepted or “eavesdropped” by unauthorised parties, and also to avoid traffic of unwanted data packets through the networks, e.g. by encryption and authorisation of the data packets. While protection against unwanted traffic is often employed at the receiver, e.g. spam filtering for e-mails or the like, basic protection against unwanted traffic of data is often lacking within the packet-switched networks.
Since IP addresses are publicly distributed by DNS systems or similar as described above, any communication party is basically able to send messages and data packets to any other communication party over the Internet, resulting in the well-known problems of flooding, spamming, virus and fraud. Hence, it has generally become a problem that any communication party can get across data packets totally out of control of the receiving communication party. Also, the transport of unwanted data packets can still consume network resources along the entire sender-receiver path, even though the packets may be discarded at the receiver anyway.
Another approach has therefore been devised to support the forwarding operation in the routers. Instead of providing the IP address of a target receiver, the DNS, or more generally a “name server”, pre-determines a distinct transmission path between a sender and a receiver and encodes all hops, i.e. the intermediate routers and/or links along the path, into a so-called “Bloom filter”, sometimes also referred to as a “zFilter”. In this process, it is assumed that the name server has sufficient knowledge of the network topology to determine the transmission path.
Briefly described, a Bloom filter is a bit-vector of some predetermined length, m, together with a set of k hash functions h1, h2, . . . hk, mapping into the set {1, 2, . . . , m}. To insert some data item, x, into the Bloom filter, bit-positions h1(x), h2(x), . . . hk(x) of the bit-vector are all set to “1”. Conversely, in order to determine if a certain candidate data item, y, is a member of a data set being encoded by the Bloom filter, bit-positions h1(y), h2(y), . . . hk(y) are checked, and if all these bit-positions are “1”, it can be assumed that y is actually a member of the data set. As a result, it may happen that Bloom filters have so-called “false positives” since the bit positions could have been set to “1” by some other element(s), different from y. However, the rate of false positives can be controlled by selecting appropriate values of m and k.
When queried by a sender for a receiver, the name server creates the appropriate Bloom filter defining the path with all intermediate links between sender and receiver, and provides it to the sender to be included in each data packet sent out towards the receiver.
Using this approach, routers will analyse the Bloom filter attached to each received data packet in order to detect if any candidate next hop link from the current router, has been encoded into the Bloom filter. When finding a match with a next hop link in this matching operation, the packet is transmitted on that link to the next router where the forwarding operation is repeated. Effectively, the Bloom filter authorises the data packet to be transmitted to the receiver. If none of the router's candidate links is found in the Bloom filter, i.e. no match, the packet is discarded for being non-authorised.
An exemplary scenario for transmitting data packets through a network with routers R using the above Bloom filter approach, is schematically illustrated in FIG. 2, involving a sender A, a receiver B, a public packet-switched network 200 with a plurality of routers R, and a name server 202. When the sender A basically makes a query Q in the name server 202 for sending data packets to the receiver B, server 202 predetermines a transmission path over four intermediate routers R1-R4 between sender A and receiver B, based on the known network topology. The transmission path includes links 1-3 connecting the neighbouring routers R1-R4 as shown in the figure. The query Q can also be seen as a request for a Bloom filter “BF” leading to receiver B.
After applying some suitable security control for determining if the sender is allowed to get across data packets to the receiver, the name server 202 then defines a BF in which at least the different links 2-4 between routers R1-R4 are encoded, and the BF is provided to sender A in response to the query Q. The sender A is then able to get across data packets to receiver B by including the BF in transmitted packets, while each router R1-R4 determines the next hop for each received packet based on the BF therein, as described above. The name server 202 can also apply various admission control functions before providing the BF to the sender to enable A to get across data packets to B.
The links in the transmission path may be defined by individual explicit link identities. Alternatively, the hops over different links may be defined by fitting ingress and egress identities in each router, e.g. port numbers. For example, a hop over link 3 between R2 and R3 can be defined by an ingress identity i2 in R2 and an egress identity e3 in R2 leading to R3, i.e. as a routing parameter or hop identity (i2,e3). In this description, the term “next hop parameter” represents any suitable information in a BF that determines the next hop in the predetermined transmission path, indicated either as a link, a next router or the above ingress/egress combination.
When receiving the packet, router R2 will match a number of candidate links or hops, one by one, with the BF in the packet. When finding a matching routing parameter (i2,e3) for link 3 that has been encoded into the BF, router R2 sends out the packet on link 3 according to egress identity e3, and so forth. If no candidate link or hop is found in the BF, the packet is simply discarded. In this way, security can be implemented in the name server for submitting a BF to the requesting sender. It should be noted that several candidate hops at the router R2 may be found to match the BF such that the packet will be sent out on all the matching links. Hence, Bloom filter based routing may also be used to implement multi-cast is a convenient way.
Nevertheless, it may be too easy for advanced hackers to derive a BF from an intercepted packet for getting across potentially unwanted data packets to the same destination. Furthermore, the forwarding operation and packet transmission is delayed since, when using BF routing schemes known in the art, each router must read and process the entire packet header before the information encoded therein can be detected and the forwarding decision can be made.